[wrangler] Allow containers to be attached to Durable Objects via exports - #15026

…ports`

A container can now be linked to its Durable Object from the export side,
using a new `container` field that names an entry in the `containers`
array:

    "containers": [{ "name": "my-container", "image": "./Dockerfile" }],
    "exports": {
      "MyContainerDO": {
        "type": "durable-object",
        "storage": "sqlite",
        "container": "my-container"
      }
    }

As a result `containers[].class_name` is now optional — a container that
is referenced this way only needs a `name`. This decouples container
configuration from the Durable Object class, which is a prerequisite for
configuring containers as standalone resources.

The link is resolved by a shared helper in `@cloudflare/workers-utils`,
used by wrangler's container normalization, the Vite plugin's dev/preview
container builds, and `unstable_getMiniflareWorkerOptions`. Upload
metadata sends both directions as configured (`containers[].name` and
`exports[].container`) so that the API can do its own resolution;
wrangler only pre-resolves for local dev and Cloudchamber app creation.

Cross-field validation now reports dangling `container` references, two
exports claiming the same container, the two directions disagreeing, a
container linked to no Durable Object, `class_name` with no live export,
and duplicate container names.

`versions upload` sends `containers[].name` alongside `class_name` now, so
this assertion needs the derived `<worker>-<class>` name. The container in
this test has no explicit `name`, which is exactly the case where
validation fills one in.

The round-trip consistency check only looked one way: it compared a
container's `class_name` against the `container` field of that same class's
export. It never asked whether some *other* export had claimed the
container, so this contradictory config was accepted silently:

    "containers": [{ "name": "x", "class_name": "Y", "image": "..." }],
    "exports": {
      "Y": { "type": "durable-object", "storage": "sqlite" },
      "MyDO": { "type": "durable-object", "storage": "sqlite", "container": "x" }
    }

`exports.Y` names no container, so the existing comparison had nothing to
compare against. Wrangler would then resolve the container to `Y` locally
while the upload metadata let the API resolve it to `MyDO`.

When more than one export claims the container, the existing
duplicate-claim error already covers it, and singling one of them out here
would make the message depend on the order of the keys in `exports`.

Reported by Devin Review on #15026.

Two containers sharing a `class_name` was accepted but could never work:
workerd attaches a single container per Durable Object namespace, and in
local dev `getDevContainerImageName` derives the image tag from the class
name alone, so both containers build into the same tag and one silently
overwrites the other. The vite plugin's map keyed by `image_tag` and
miniflare's `Map<className, { container? }>` each drop one too.

The cross-field validation added in this branch made that latent problem
incoherent rather than fixing it. The same config was accepted, rejected as
a link "disagreement", or rejected as a duplicate derived name depending on
incidental details:

  a, b both `class_name: MyDO`, no export names either  -> accepted
  a, b both `class_name: MyDO`, `exports.MyDO.container: a` -> "disagreement"
  two unnamed containers on MyDO -> duplicate name "worker-mydo"

All three now report the same root cause. The round-trip checks are skipped
for an over-subscribed class so they no longer blame a container for a
sibling owning the class's `container` field.

The claim that a Durable Object could be backed by several containers was
introduced earlier in this branch, in a doc comment and a test; both are
corrected. `cloudchamber/apply` had a two-application test that copied
`class_name` via a spread, so the second app now gets its own class.

Reported by Devin Review on #15026.

`exports` is inherited by named environments but `containers` is not, so
the idiomatic multi-environment layout declares `exports` once at the top
level and repeats `containers` in each environment. The top level pass then
saw an `exports[Class].container` reference with no containers to match it
against and reported it as dangling.

Because that pass writes to the root diagnostics, the error surfaced even
when a named environment was selected, so the config could not be loaded
for any environment.

The existing guard only covered the mirror case, where a named environment
inherits `exports` without redeclaring `containers`. Generalise it to skip
the cross-check whenever the containers are declared at a different
environment level, in either direction.